The present invention relates generally to object-based high level programming environments, and more particularly, to storing and retrieving of field descriptors in Java computing environments.
Recently, the Java programming environment has become quite popular. The Java programming language is a language that is designed to be portable enough to be executed on a wide range of computers ranging from small devices (e.g., pagers, cell phones and smart cards) up to supercomputers. Computer programs written in the Java programming language (and other languages) may be compiled into Java Bytecode instructions that are suitable for execution by a Java virtual machine implementation.
The Java virtual machine is commonly implemented in software by means of an interpreter for the Java virtual machine instruction set but, in general, may be software, hardware, or both. A particular Java virtual machine implementation and corresponding support libraries together constitute a Java runtime environment.
Computer programs in the Java programming language are arranged in one or more classes or interfaces (referred to herein jointly as classes or class files). Such programs are generally platform, i.e., hardware and operating system, independent. As such, these computer programs may be executed without modification on any computer that is able to run an implementation of the Java runtime environment.
Object-oriented classes written in the Java programming language are compiled to a particular binary format called the “class file format.” The class file includes various components associated with a single class. These components can be, for example, methods and/or interfaces associated with the class. In addition, the class file format can include a significant amount of ancillary information that is associated with the class. The virtual machine loads the class file and internally represents the information as an “an internal class representation”. The class file format (as well as the general operation of the Java virtual machine) is described in some detail in The Java Virtual Machine Specification, Second Edition, by Tim Lindholm and Frank Yellin, which is hereby incorporated herein by reference.
As an object-oriented programming language, Java utilizes the programming concept known as an object. In the Java programming environment, Java objects are created (instantiated) from Java classes. Typically, Java objects are stored in a heap memory portion (heap). To illustrate, FIG. 1 depicts a computing environment 100 including a heap memory portion 102 suitable for storing Java objects. As shown in FIG. 1, various Java objects, for example, objects O1, O2, O3, O4, O5 and O6 can be stored in the heap memory portion 102. A Java object in the memory portion 102, for example, Java object O3, can include a reference to its class, as well as one or more other fields describing data (e.g., variables) associated with the object. The Java object O3 can also include references to other Java objects, for example, Java objects O4 and O5, which are also stored in the heap memory portion 102.
Java objects are typically created in the heap memory portion 102 when they are instantiated. After a Java object has been instantiated, it can be referenced from various points in the Java program. For example, the object O3 can be referenced by a local variable 104 of the Java program. During the execution time of the Java program, as depicted in FIG. 1, the local variable 104 can be on an execution stack 106 in a stack frame portion 108. The stack frame portion 108 represents the stack frame for a method associated with the local variable 104. The stack frame portion 108 is typically placed on the execution stack 106 when the associated method is invoked.
In addition to the local variables associated with the method, the stack frame portion 108 also includes an operand stack portion 110 suitable for placing various operands on the execution stack 106. In the Java programming environment, these operands are placed on the operand stack portion 110 of the execution stack 106 in order to execute the Java method associated with the stack frame 108. As is known to those skilled in the art, these operands can be references to objects stored in the heap memory portion 102, e.g., an operand 112 referencing the Java object O3.
As is known to those skilled in the art, there may be a need to identify and track references to Java objects for various reasons. For example, during the course of the execution of Java programs, some of the objects in the heap memory portion 102 are no longer needed (i.e., become “dead objects” which are no longer reachable by the Java program). Accordingly, it is desirable to identify the “dead” objects in the heap memory portion 102 and remove them from the heap. This operation can be referred to as “garbage collection.”
To perform garbage collection for Java programs, there is a need to identify references to Java objects from various “root points.” The root points include references on the execution stack and static variables. As noted above, a Java object can reference other Java objects. In other words, one or more fields of the Java object may reference other Java objects which may, in turn, have fields that also reference Java objects. This means that there is a need to determine whether the fields of Java object are references to other Java objects.
To accomplish this, the type descriptor for the fields have to be located and accessed. Then there is a need for more processing to determine whether a given field is a reference to a Java object, since each type descriptor can be a reference. It should be noted that locating and accessing type descriptors are performed at run time (e.g., by a garbage collector). In some cases, these operations have to be performed again and again during the execution of the program for the same Java object. Thus, conventionally, significant processing power and time has to be devoted to repeatedly locate the type descriptors and determine which one of the fields are references to Java objects. This can have serious effects on the runtime performance of virtual machines, especially those operating with limited resources (e.g., embedded systems).
In view of the foregoing, alternative techniques for storing and retrieving Java field descriptors are needed.